-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[STACKED] Reject relaxed bounds inside associated type bounds (ATB) #135331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
@bors try |
[crater-only] Ban assoc ty unbounds cc rust-lang#135229 r? ghost
☀️ Try build successful - checks-actions |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
Based on running Crater Analysis on this crater report full automated report
|
Only relevant to the internal feature `more_maybe_bounds`.
We no longer move trait predicates where the self ty is a ty param to "the bounds of a ty param".
* The phrasing "only does something for" made sense back when this diagnostic was a (hard) warning. Now however, it's simply a hard error and thus completely rules out "doing something". * The primary message was way too long * The new wording more closely mirrors the wording we use for applying other bound modifiers (like `const` and `async`) to incompatible traits. * "all other traits are not bound by default" is no longer accurate under Sized Hierarchy. E.g., traits and assoc tys are (currently) bounded by `MetaSized` by default but can't be relaxed using `?MetaSized` (instead, you relax it by adding `PointeeSized`). * I've decided against adding any diagnositic notes or suggestions for now like "trait `Trait` can't be relaxed as it's not bound by default" which would be incorrect for `MetaSized` and assoc tys as mentioned above) or "consider changing `?MetaSized` to `PointeeSized`" as the Sized Hierarchy impl is still WIP)
Having multiple relaxed bounds like `?Sized + ?Iterator` is actually *fine*. We actually want to reject *duplicate* relaxed bounds like `?Sized + ?Sized` because these most certainly represent a user error. Note that this doesn't mean that we accept more code because a bound like `?Iterator` is still invalid as it's not relaxing a *default* trait and the only way to define / use more default bounds is under the experimental and internal feature `more_maybe_bounds` plus `lang_items` plus unstable flag `-Zexperimental-default-bounds` (historical context: for the longest time, bounds like `?Iterator` were actually allowed and lead to a hard warning). Ultimately, this simply *reframes* the diagnostic. The scope of `more_maybe_bounds` / `-Zexperimental-default-bounds` remains unchanged as well.
TraitRef<AssocTy: …>
)
TraitRef<AssocTy: …>
)TraitRef<AssocTy: …>
)
TraitRef<AssocTy: …>
)5c245de
to
e7050cb
Compare
r? types |
@rfcbot fcp merge |
Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
…er-errors More robustly deal with relaxed bounds and improve their diagnostics Scaffolding for rust-lang#135229 (CC rust-lang#135331) Fixes rust-lang#136944 (6th commit). Fixes rust-lang#142718 (8th commit).
…er-errors More robustly deal with relaxed bounds and improve their diagnostics Scaffolding for rust-lang#135229 (CC rust-lang#135331) Fixes rust-lang#136944 (6th commit). Fixes rust-lang#142718 (8th commit).
Caution
STACKED on top of PR #142693 (approved, in the queue). Only the last commit is relevant!
Reject relaxed bounds — most notably
?Sized
— inside associated type boundsTraitRef<AssocTy: …>
.This was previously accepted without warning despite being incorrect: ATBs are not a place where we perform sized elaboration, meaning
TraitRef<AssocTy: …>
does not elaborate toTraitRef<AssocTy: Sized + …>
if…
doesn't contain?Sized
. Therefore?Sized
is meaningless. In no other (stable) place do we (intentionally) allow relaxed bounds where we don't also perform sized elab, this is highly inconsistent and confusing! Another point of comparison: For the desugared$SelfTy: TraitRef, $SelfTy::AssocTy: …
we don't do sized elab either (and thus also don't allow relaxed bounds).Moreover — as I've alluded to back in #135841 (review) — some later validation steps only happen during sized elaboration during HIR ty lowering1. Namely, rejecting duplicates (e.g.,
?Trait + ?Trait
) and ensuring thatTrait
in?Trait
is equal toSized
2. As you can probably guess, on stable/master we don't run these checks for ATBs (so we allow even more nonsensical bounds likeIterator<Item: ?Copy>
despite T-types's ruling established in the FCP'ed #135841).This PR rectifies all of this. I cratered this back in 2025-01-10 with (allegedly) no regressions found (report, its analysis). However a contributor manually found two occurrences of
TraitRef<AssocTy: ?Sized>
in small hobby projects (presumably via GH code search). I immediately sent downstream PRs: Gui-Yom/turbo-metrics#14, ireina7/summon#1 (however, the owners have showed no reaction so far).I'm leaning towards banning these forms without a FCW because a FCW isn't worth the maintenance cost3. Note that associated type bounds were stabilized in 1.79.0 (released 2024-06-13 which is 13 months ago), so the proliferation of ATBs shouldn't be that high yet. If you think we should do another crater run since the last one was 6 months ago, I'm fine with that.
Fixes #135229.
Footnotes
I consider this a flaw in the implementation and I've already added a huge FIXME. ↩
To be more precise, if the internal flag
-Zexperimental-default-bounds
is provided other "default traits" (needs internal featurelang_items
) are permitted as well (cc closely related internal feature:more_maybe_bounds
). ↩Having to track this and adding an entire lint whose remnants would remain in the code base forever (we never fully remove lints). ↩